Architektur und Arbeitsweise eines Web-Browsers 



Hauptseminar 
„Datenbank- und Informationssystemc" 
WS 2000 

Markus Legner 
Betreuer: Dipl.-lnf. Aiko Frank 
14.01.2001 



Inhaltsverzeichnis 

1 Einleitung 2 

2 Browser allgemein 2 

2.1 Logische Architektur eincs Browsers 2 

2.2 Browserkonzepte 3 

2.2.1 DOM und DHTML Object Model 3 

2.2.2 client-basierte Skriptausflihrung 5 

2.2.3 Java Virtual Machine (VM) 5 

2.2.4 MIME-Typen 6 

2.2.5 Cookies 6 

2.2.6 Cache 6 

2.3 Der Prozefi der Seitenerzeugung 7 

2.3.1 Parser Komponenten 7 

3 Mozilla / Netscape Navigator 7 

3.1 Plug-in API 7 

3.2 LiveConncct 8 

3.3 Gecko Layout Engine 9 

3.4 Mozilla ActiveX Control 10 

4 Microsoft Internet Explorer (IE) 10 

4.1 ActiveX 10 

4.2 Architektur des IE 11 

4.3 ActiveX Scripting Engine 12 

4.4 Browser Extensions 12 

4.5 Shell Helper API 13 

4.6 WebBrowser Control 13 

5 Zusammenfassung und Ausblick 13 



1 



1 Einleitung 



Was verbindet einen Browser mit Datenbank- oder Informationssystemen? 

Selbst der Laic crkcnnt recht schnell, dafi ein Browser, fur sich alleine, recht wenig mit der Verwaltung 
von Daten und Informationen zu schafFen hat. Worin besteht also der Zusammenhang, der den Bereich 
Web-Browser fur das Oberthema dieses Seminars relevant macht? 

Ein IS 1 hat nur einen Nutzen, wenn die verwalteten Daten in geeigneter Weise genutzt werden konnen. 
Das heifit, ein Benutzer mufi 

• die relevanten Daten, 

• am richtigen Ort, 

• zur richtigen Zeit, 

• auf einfache Art und Weise 
abrufen konnen. 

Iiierfur bieten bcreits cxisticrcndc Wcbtcchnologien selir gute Voraussetzungen. Ein Wcb-Browscr 
bictet cine gewohnte, im Grunde relativ einfach zu bedienende Oberftache. Aufierdem kann durch 
den flexiblen, nicht fest verdrahtctcn Zugriff iiber das Netzwerk von verschiedenen Standorten, zu 
beliebigen Zeiten zugegriffen werden. Ein weitercr positiver EfTckt, bci der Nutzung von Internettech- 
nologie. ist die Verminderung von Kosten fur Kauf und Installation von speziellen Anwendungcn. Dies 
ist die Folgc daraus, dafi ein Browser fur den Datenzugriff ausreichend ist. 

Diese Vorteile machen sich viclc Unternehmen verstarkt zunutze. Heutzutage findet sich kaum noch 
cin grofieres Unternehmen, das nicht ein eigenes Intranet betreibt, urn die Informationsinfrastruktur 
und somit die Produktivitat und Effizienz der Mitarbeiter zu verbessern. Nahezu alle wichtigen 
Produzenten von Unternehmenssoftware haben den Trend ebenfalls erkannt, und bieten mittlerweile 
Web-Schnittstellen fur ihre Produkte. 

Entscheidend ist, dafi cin Browser nicht nur die Standardfunktioncn iibernchmcn kann. Dies sind 
Funktionen wic das Darstellen von statischen HTML- und XML- Seiten. die Unterstiitzung von Links 
oder die Fahigkeit Bilder darstellen zu konnen. Ein Browser mufi auch Erweiterungsmoglichkeiten 
bieten, so dafi z.B. komplexere Bedienschnittstellen, oder die Verarbeitung proprietarer Datenformate 
realisiert werden konnen. Dies wird u. a. ein Thema dieser Arbeit sein. 

2 Browser allgemein 

2.1 Logische Architektur eines Browsers 

Es lassen sich - auf einer schr abstraktcn Ebcne - die folgenden logischen Komponenten cines Browsers 
unterscheiden: 

Der Controller ist die zentrale Komponcntc, die die Ablaufe im Browser rcgelt und uberwacht. In 
ihm werden auch alle Eingaben des Benutzers verarbeitet. Beim Browser ist dies normalerweise auf 
Maus- und Keyboarde vents beschrankt. Ein Beispiel fur eine Benutzeraktion ware das Anfordern 
einer neuen URL 2 durch den Benutzer. 

1 Inforinatioiissysteni 

2 Uniform Ressource Locator 
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Abbildung 1: Der logische Aufbau cines Wcbbrowsers 

Der HTML Client ist dafiir verantwortlich, einen Teil der dem Controller mittgeteilten Auftrage 
auszufuhren. Im Falle des HTML CLient betrifft das vor allem das Anfordern von HTML Seiten 
iiber <las Netzwerk. Der HTML Client bedient sich dazu der Netzwerkkoinponente. Sie kontaktiert 
den entsprechenden Webserver iiber HTTP 3 und liefert die Ergebnisse zuriick. 

Der HTML Interpreter trilt dami in Aktion. wenn die Informationen aus dern neu empfangenen 
HTML-Dokument grafisch auf dem Monitor darzustellen sind. Der Interpreter wird vom Controller 
aufgerufen, wenn ein neues Dokument empfangen wurde. Er parst den HTML-Code und liefert die 
Ergebnisse an den Grafiktreiber Wie die Erzeugung der grafischen Ausgabe ablauft wird in einem 
der folgenden Kapitel genauer besproclien. 

Neben dem HTML Client finden sich in heutigen Browscrn noch cine Vielzahl anderer Clients. Bei- 
spiele hierfiir ware der FTP^ Client, oder ein Gopher Client 5 . 

Wie es verschiedene Clients geben kann, so kann es auch verschicdcnc Interpreter - zum Darstellcn 
von Dokumenten, die in verschiedenen Sprachen vorliegen - geben. Ein Beispiel hierfiir ware ein 
XML 6 Interpreter, der XML-Dokumente verarbeiten kann. 

2 . 2 Browser konzepte 

2.2.1 DOM und DHTML Object Model 

Ehemals warcn allc IITML-Seiten statischer Natur. Das bedeutet, die Seite wurde iiber das Netz 
gelesen. ausgewertet und einfach auf dem Bildschirm ausgegeben. Am Anfang war die Representation 
der Seiten im Browser total „flach". Das bedeutet es best and keine Moglichkeit einzelne Teile der 
Seite zu andern, z. B. waxen die Tags nicht direkt adressierbar. Ein HTML-Dokument wurde genau 
einmal abgearbeitet und dargestellt. 

Mit der Weiterentwicklung des Internets reichten diese Datenstrukturen aber nicht mehr aus. um die 
gewunschte Interaktivitat zu erreichen. Die Konsequenz war die Standardisierung des Datenmodells 
durch das W3C 7 . Das Resultat hieraus ist das Document Object Model (DOM). 

3 Hypertext Transfer Protocol 
4 File Transfer Protocol 

5 Veralteles Protokoll, das zurn Suchen nach Themen im Internet verwendet wurde, und teilweise noch wird. 
6 Extended Markup Language 
7 World Wide Web Consortium|6] 
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DOM Das DOM ist eine plattform- und sprachunabhangigc Schnittstelic. Sie erlaubt es iiber 
Skriptsprachen auf den Inhalt, die Struktur und den Stil eines Dokumentes zuzugreifen, und diese zu 
andern. Das DOM umfasst ein Modell, das beschreibt, wie eine standardisierte Menge von Objek- 
ten, die HTML- und XML-Dokumente reprasentieren, koinbiniert werden kann. Weiter beinhalted es 
noch eine Sennit tstelle. die es ermoglicht diese Objekte zu adressieren und sie zu manipulieren. Ein 
Hauptvorteil des DOM ist die Moglichkeit, auf ailes im Dokumcnt ZugrifF zu haben, was beliebige 
Aktualisierungen erlaubt. Zusatzlich kann auf einzelne Fragmente des Dokuments gezielt zugegriffen 
werden. 

Die DOM-Spezifikation ist in mehrere Level und darin noch in verschiedene Bereiche gegliedert. Im 
folgenden werden kurz zwei Bereiche aus dem crsten Level beschrieben: 

• Document Object Model Level 1 (Kern) 

Diese Stufe definiert eine minimale Menge von Objekten und Sennit tstellen um auf Dokumenten- 
Objekte zugreifen zu konnen und sie zu bearbeiten. Die Kern-Stufe bietct cine allgemeine API 
um bereits geparste HTML- und XML-Inhalte verarbeiten zu konnen. AuBerdem erlaubt sie 
es Dokumcntc komplett im Hauptspeicher aufzubauen. Das persistente Speichern bleibt dem 
Programmierer iiberlassen. 

• Document Object Model Level 1 (HTML) 

Die HTML-Stufe erweitert den Kern um Objekte und Methoden, die spezifisch in HTML- 
Dokumenten Verwendung finden. Der Kern enthalt allgemein Spezifikationen, die benotigt 
werden um hierarchische Strukturen, Elemente und Attribute zu bearbeiten. Hier - im HTML- 
Bereich - wird Funktionalitat definiert, die spezifischen HTML-Elementen zugeordnet ist. Sie 
ist also nicht global nutzbar. 

Aktuell ist zur Zcit Level 6, wobei jedes Level ca. sechs Bereiche hat, so dan hier aus Flalzgi linden 
nicht darauf eingegangen werden lcann. Nach meinem Wissens implcmentieren die aktuellen Brow- 
sergenerationen bcstcnfalls Tcile von Level 2. Die Spezifikationen finden sich auf der Homepage des 
W3C[6]. 

DHTML Object Model Das DHTML Object Model ist eine schwacher ausgepragte, weniger 
strukturierte Form des DOM. Wahrend das DOM wie erwahnt vom W3C standardisiert ist, ist das 
jeweilige DHTMLOM abhangig von der Spezifikation des Browser-Herstellers. Es gestattet Autoren 
direkten, programmierfahigen Zugriff auf die einzelnen Komponenten ihres Web- Dokumentes - von 
einzelnen Elementen bis hin zu Container*,. Der Zugriff iiber das DHTMLOM kornbiniert mit dem 
Event Model erlaubt z. B. die folgenden Aktionen: Reaktion auf Benutzereingaben, Ausfiihrung von 
Skripten , } on-the-fly" oder die Anzeige neuer Inhalte ohne den Sei*ver zu kontaktieren. 

Beide Modelle stimmen darin iiberein, dan jedes Element und jedes Attribut iiber Skript erreichbar 
ist. Es gibt aber audi ein paar Unterschiede. Das DOM ist eine Weiterentwicklung des DHTMLOM 
mit dem Zweck mehr Robustheit zu erreichen. Im Gegensatz zum DHTMLOM ist das DOM viel 
starker strukturiert, und es bietet eine logische Schnittstelle fiir den Zugriff und das Andern der 
Elemente und Attribute. 

Die Manipulation des Dokument-Baums mittels DOM hat folgende Vortcilc: 

• Ein Teil des Baumes kann an eine andere S telle geschoben werden, ohne den Inhalt loschen und 
wieder hinzufiigen zu miissen. 

• Neue erstellte Dokuinente konnen an jeder Stelle im Baurn eingehangt werden. 

• Einzelne Zweige konnen innerhalb eines Dokumenten-Fragmentas organisiert und verandert 
werden. Erst danach werden die Objekte wieder in den Baum eingefiigt. 
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DHTML OM 



window. onloadsCnlnlc; 
vtiL iSbuCClc; 
Junction CnlnitO ( 

isnurtie-oLisfc. children, lengtn-i; 

) 

tunc cion CnOliuf £ lc I ten ( ) ( 

vot oChildrcn-oLiot. children; 
ir(isnutEie<=u) ( 

iflhlirrii*anrtii I <tt »-n. Ir-r.ijl.il- I ; 
vftE aData-odiildcenCOl . outecimn. ; 
o Chi 1 dr cn [ 0 ] . ou tc rHTH L - " " t 
olxsz. xnner«TJU.->.*siiata; 

> 

var sSwapl-oCMldrenfiShutfla-l] . outarHTHL 
wax 95W6p2=ocnii<Jren[ismii:cj.e].o\iterHTML; 
uCUlldLt:ii[i3Uuf £le-l ] .uuLcLHTML*'33wag2; 
oChildccnf iShuCClcl . outcrfTTHL-aSvapli 
i Shuttle — ; 



DOM 

h t ihImm . i in 1 1 tml— frtTri i I.; 
vat u3hul£lc; 
function £nlnit()« 

o3huf f lc-oLiat , iaotChild; 

J 

function f nShuf f lcltcn><) ( 

var oSvap-cShuff la .previouaSibiing; 
it I (OSvap) { 

oSuep-oList . lasci.niici 

> 

oShutlle . awapNode (osusp) ; 

> 



Abbildung 2: Vergleich zwischen DHTML- und DOM-Programmierung [2] 

2.2.2 client-basierte Skriptausfiihrung 

Ein Skript ist ein Programin - in einer Skriptsprache geschrieben - , das nicht compiliert wird, sondem 
das zur Laufzeit von einem Interpreter ausgefuhrt wird. Wie ohen bereits angesprochen geben Skripte 
einer Web-Seite Dynamik, da es iiber die beschriebenen Modelle moglich ist den Inhalt der Seite „zu 
programmiereir 1 . 

Skripte in Web-Seiten werden auf dem Client/ Web-Browser ausgefuhrt und errnoglichen somit mehr 
Funktionalitat und sogar Iriteraktivitat zu erreichen. Server-seitig erlauben Skripte hingegen dyna- 
misch HTML-Seiten zu erzeugen (welche wieder client-seitige Skripte enthalten konnen). 
Im Internet gibt es prinzipiell zwei mogliche Orte den Skriptcode in einer Seite auszufuhren: Webser- 
ver oder Browser. Hier soil nur die 2. Variante betrachtct werden. 

Die Skriptinterpreter im Browser werden normalerweise als Script- Engines (SE) bezeichnet. Beim 
Laden der Seite lafit der Browser den Skriptcode vom korrekteu SE interpretieren. Wird in einer 
Seite ein Event 8 ausgelost, so fuhrt der Browser den dem Event zugeordneten Skriptcode aus. 

Ein Problem der client-basierten Skriptausfiihrung ist natiirlich die Kompatibilitat zwischen den 
Browsern, was deren Ausstattung betrifft. Wird eine Skriptpassage vom eigenen Browser korrekt 
interpreter t j so kann man deswegen noch lange nicht annehmen, dafi dies tatsachlich jeder Browser 
kann. Dieses Problem tritt natiirlich beim server-basierten Ansatz nicht auf, was auch dessen grower 
Vorteil ist. 

2.2.3 Java Virtual Machine (VM) 

Um aktivc Java-Inhalte zu verwenden bedarf es eines java~fahigen Browsers 9 . Java Applets, die in 
einer Webseite enthalten sind, werden immer innerhalb einer speziellen Komponente, der sogenann- 
ten Java Virtual Machine aiLsgefiihrt. Die VM ist durch die Schnittstellen-Spezifikation von Sun 
festgelegt. Mittlerweile gibt es fur fast alle Plattformen entsprechende VMs. Es ist jederzeit moglich 
eine eigene VM zu implementieren, solange sie die speziflzierte Schnittstelle umsetzt. So verwendet 
der Internet Explorer beispielsweise eine eigene JVM. die auf ActiveX (4.1) basiert. 

8 Engl.: Ereignis. Eine Nachricht, die einer bestirnmten Komponente raitteilt, dafi eine bestimrnte Aktion ausgefuhrt 
wurde. 

9 z.B. die aktucllcn Browser von Netscape oder Microsoft 
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2.2.4 MIME-Typen 

MIME steht fur Multipurpose Internet Mail Extension. MIME ist erne standardisierte Methode 
fur die Organisation von verschiedenen Datciformaten. Dabei werden Dateien nach ihreni jeweili- 
gen MIME-Typ, der das Format beschreibt organisiert. Liefit der Browser eine Datei von einem 
Webserver, so liefert der Server den MIME-Typ der Datei rait. HTTP-Server verwenden z.B. die 
HTML-Formatierung ( : ,tcxt/html"). Der Browser bestimmt anhand des MIME-Typs. ob cr die Da- 
ten von sich aus verarbeiten kann, oder ob zusatzliche Software benotigt wird, die er in diesem Fall 
dann, auf dem System, suchen wiirde. 

Zwar unterstiitzen viele Plattformen wie zum Beispiel Windows Standardverkniipfungen zwischen 
Dateinamenerweiterungen und Dateitypen. Doch ist diese Verkniipfung nicht eindeutig genug. So 
kann die Dateinamenerweiterung „.doc" beispielsweise ein Word-Dokument. ein FrameMaker-Dokuinent 
oder eine einfachc Tcxtdatei bedeuten. Das System der Mime-Typen hat die Aufgabe, solche Zweideu- 
tigkeiten zu beseitigen und den beteiligten Programmen (WWW-Server-Software, WWW-Browser) 
ein eindeutiges Identifizierungsschema fiir den Datentyp von Dateien bereitzustellcn. 

MIME-Typen werden nach folgendem Schema arigegeben: 
Kategorie/Unterkategorie 

Kategorien sind z.B. text, image, audio. Unterkategorien von text sind beispielsweise plain (Datei 
ist eine reine Textdatei) oder html (Datei ist eine HTML-Datci). Unterkategorien von image ist 
beispielsweise gif (Datei ist eine Grafik im GIF- Format). 



2.2.5 Cookies 

t?:„ 11 0-«kU«, T^*-,-»™r»+o Icf A\t± 7.no+ori^c1r>o;frl/i3;i' rloo Pr/M rvlrkll c ftnf Hptd AicrpntlirH 

XUX li UUUiCgOllU^O A IWUlUin \Al*J uiiwav-uu v*"- •— ^i'w^^w^q.^xv - — 7 --O" 

das gauze Netz basicrt: HTTP. Das bedeutet, jeder neue Seitenaufruf ist fiir Webserver und -browser 
vollig isoliert. Wird eine Seite zeitlich getrennt zwei mal aufgerufen, so weifi der Webserver beim 2. 
Aufruf normalerweise nichts von dem ersten Besuch der Seite. Als das Internet, wie wir es heute 
kennen, konzipiert und in Betrieb genommen wurde. war dieses Manko noch nicht so gravierend wie 
heute rnit neuen Technologies wie sie z. B. fiir E-Commerce benotigt werden. 

Die Losung des Problems sind u. a. Cookies; dt.: Kekse. Das sind kleine Textdateien, die vom Brow- 
ser in einem bestimmten, ausgezeichneten Verzeichnis abgelegt werden 10 . In den Cookies werden 
lnformationen abgespeichert, die ein Webserver zu einem spaterem Zeitpunkt eventuell benotigt. 
Diese lnformationen sind nur vorn „besitzcnden" Webserver abrufbar, und der Benutzer kann die 
Verwendung von Cookies expizit verbietcn. 

Cookies miissen nicht zwingend auf der Festplatte des Browsers abgelegt werden. Das ASP 11 - 
Sessionmanagement verwendet z. B. Cookies, die im Speicher des Client-Rechners abgelegt werden. 
Bei nachfolgenden Anfragen an den selben Server werden dann die Cookie-Informationen wieder 
mitgeschickt. 

2.2.6 Cache 

Die Funktion des Caches unterscheidet sich im Browser nicht von anderen Systcmcn. Deshalb wird 
hier nur kurz darauf eingegangen. 

In einem Netzwerk ist es klar, dafi Zugriffe liber das Netzwerk um ein Vielfaches teurer sind, als 
lokale Datenzugriffe. Der Cache im Browser hat die Funktion eine lokale Kopie jeder gelesenen Seite 
zu halten. Soli eine Seite neu angefordert werden, so priift der Browser zunachst, ob die Seite nicht 

10 unter Win 2000 z. B. im „ Cookies" -Verzeichn is, im Homeverzeichnis des Benutzers 
11 Active Server Page 
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lokal im Cache liegt. 1st dies der Fall, so wird nur die lokalc Kopic verwendet, und der teure Zugriff 
iiber das Netz wird vermieden. Wird die Seite nicht im Cache gefunden, so ist der Zugriff iiber das 
Netzwcrk natiirlich unvermeidbar. 

Die Caching-Funktion des Browsers laflt sich auf drei Wciscn abschalten. Am einfachsten ist die 
Caching- Konfigiiration iiber das Menu des Browsers. Die zweite Moglichkeit, ist das Vermeiden des 
Zwischenlagerns mittels eines speziellen HTTP Cache-Control Headers. Zu guter letzt kann eine 
HTTP-EQUIV META Tag in der HTML-Datei verwendet werden, dessen Interpretation allerdings 
browserabhangig ist. 



2.3 Der Prozefi der Seitenerzeugiing 
2.3.1 Parser Komponenten 

Die folgenden Komponenten sind auf dem V/eg vom HTTP-Stream zuin DOM beteiligt: 

• Scanner Der Scanner liefert eine API 12 , die z.B. folgcnde Aktionen gestattet: Zugriff auf 
Zeichen im Input Stream, Auffindcn bestimmter Zeichensequenzen, Anpassen der eingehenden 
Datcn und das Uberspringen unerwunschter Daten. 

« Parser Der Parser ist dem Scanner nachgelagert. Br kontrolliert und koordiniert die Akti- 
vitaten der anderen Komponenten im Layoutsystem. Wahrend die rcstlichen Komponenten in 
Abhangigkeit vom Typ der Quelldatei dynamisch ausgetauscht werden mussen, ist es selten 
notwendig den Parser zu andern. Der Parser ist audi zustandig fiir die Bildung von Tokens 1 ' 6 . 
Die grammatikalischen Regeln eines Dokumenttyps werden dynamisch angepasst. 

^mr\ tr j_ _ 1 4 "L ,* X. i- "D A'^ Iz-nvraVi a nAl/nmon+O D KV> <T7 IT VATTl V)p\- 

kiimenttyp. Fiir HTML legt sie die Menge von Tags, die zugeordnetcn Attribute und die Ver- 
schachtclungsregeln fiir Tags fest. Durch die Kapselung der Strukturinformationen wird das 
System dynamischer. 

• „Auffangbecken" Diese letzte Komponente ist eine cinfache API, die Teile des vom Parser 
erstellten Parse-Baumes als Eingabe akzepticrt, und daraus, entsprechend dem zugrundeliegen- 
de Object Model, das Objekt, das das Dokument reprasenticrt, konstruiert. Der Parser hat von 
sich aus keine Informationen iiber das OM. 



3 Mozilla / Netscape Navigator 

Weitere Informationen zu diesem Kapitel finden sich im Internet. Die Homepage des MozzZZa-Projekts 
[4] bietet vor allem Informationen zu konkreten Implcmentierungsfragen. Demgegenuber sind die 
Informationen auf der Netscape-Developcr-Seite [5] ehcr iibergeordnet. Hier gibt es Informationen zu 
verschiedenen SDK's 15 und APIs. 



3.1 Plug-in API 

Die normalen Stand ardsprachen im Web sind HTML oder XML, d.h. normalcrweise ladt cin Browser 
eine HTML- oder XML-Seite und er weifi, wie cr diese darzustellen hat. Natiirhch ist die reale Welt 
nicht auf diese beiden Dateiformate beschrankt, es mufite also die Moglichkeit geschaffen werden viele 
verschiedene Dateiformate darzustellen. Man konnte zwar hergehen, und den Browsercode bei jedem 

12 Application Programming Interface 

13 Z. B. die Konvertierung einer eingehenden unstrukturierten Zeichenkette in HTML Tags. 
14 Documenl Type Definition 
15 Software Development Kit 
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neuen Format erweitern, in der Praxis ware das aber zu inefficient. 

Der erste Losungsansatz sind die sogcnannten Helper Applications. Das heiflt nichts anderes. als dafi 
der Browser bei einem ihiu fremden Dateiformat eine vollstandig auflerhalb des Browser-Prozesses 
ablaufende, externe Applikation aufruft, die das Format darstellen kaim. Die Wahl der richtigen 
Applikation ist vom MIME-Typ der Datei abhangig. Die Losung hat natiirlich den Nachteil, dafi 
der Browser die Kontrolle an die Applikation abgeben mufi und somit kcincn Einflufi mehr auf 
nachfolgende Aktioneri hat. 
Der zweite Losungsansatz sind die Plug-ins. 

Ein Plug-in ist ein separates Modul, das sich verhalt. als ware es ein Teil des Browsers. Die Plug-in API 
kann dazu verwendet werden, Plug-ins zu erstellen, die dem Browser interactive und multimediale 
Fahigkciten verleihen. Die erstellten Plug-ins konnen einem oder mehreren MIME-Typen zugeordnet 
werden. Der Browser erstellt die Zuordnungstabelle beim Programmstart. Dabei werden alle Plug-ins, 
die im ausgewiesenen j; Plug-in-Ordner" liegen, nacheinander durchlaufen und abgefragt. 

Wird eine VVebseite aufgerufen, die eingebettete „ Plug-in- Da ten" cntlialt so checkt der Browser 
zunachst, ob der MIME-Typ einem Plug-in zugeordnet ist, Ist ein passendes Plug-in installiert, so 
passiert folgendes: der Code wird in den Hauptspeicher geladen, das Plug-in wird initialisiert und 
schliefilich wird eine ncue Instanz des Plug-ins erzeugt. Verlafit der Benutzer die Webseite, oder wird 
das Browserfenster geschlossen, so wird die Plug-in Instanz zerstort. 

Die Plug-in API soil folgende Ziclc erreichen: 

• Erweiterung der Fahigkeitcn des Browsers 3 indem Inline Viewer 16 erstellt werden konnen. Diese 
unterstutzen Dateiformate, die der Browser nicht von sich aus untcrstiitzt. 

* Die Plu°"-in API, ist einfach und klein. Dies ermoglicht es relativ pmi^rh pyistiereTiHe Riblin- 
theken wieder zu verwenden, oder bestehende Applikationen fiir den Einsatz im Web zu kon- 
vertieren 17 . 

Plug-ins konnen aufierdem das Java Runtime Interface (J III) verwenden, um auf die Java-Umgebung 
zugreifen zu konnen. Die Kommunikation mit und iibcr Java, mittels JavaScript funktioniert iiber 
eine Live Connect- Verbindung (3.2). 

3 . 2 LiveConnect 

Seit dem Navigator 3.0 bietet Netscape den Entwicklern die Moglichkeit Java und JavaScript fur 
die Interaktion mit einer Webseite zu verwenden. Dies komite z.B. iiber eine Plug-in Komponente 
oder iiber die Bcnutzerschnittstellc geschehen. So konnen einige Plug-ins iiber JavaScript gesteuert 
werden. 

Obwohl Plug-ins mit Java wie auch Java mit JavaScript direkt interagieren konnen, interagieren 
JavaScript und Plug-ins nicht direkt miteinander. LiveConnect bietet die Schnittstelle fiir die Kom- 
munikation zwischen alien drei Technologien. 




LtvoCdnnect envjrcnmenr 



Kieinc Programme, die die Daten im Browserfenster darstellen. 
z. B. das Adobe Acrobat Plugin zum darstellen von PDF-Dateien 



8 



Soil ein Plug-in LiveConnect untcrstiitzen. so mufi der Standard-C-Code etwas erweitert werden. 
Zusatziich zuin eigentlichcn Code mussen die Plug-in- API -Methoden implementiert werden, die es 
dem Plug-in erlauben mit dem Java Object Model zu interagiercn. 

3.3 Gecko Layout Engine 

Der Gecko Layout Engine (GLE) basiert auf einem plattformunabhangigen Objekt-Modell: XP- 
COM™. Wie der Name schon sagt handelt es sich dabei um cine plattformunabhangige Weiter- 
entwicklung des Standard- COM. Alle Komponenten des GLE benutzen XP-COM fiir die Kommuni- 
kation untereinander. 

Die Hauptziele bei der Entwicklung des GLE waren einen kleinen. erweiterbaren und schnellen Layout 
Engine zu schaffen. Der GLE kann um beliebige Dokument en- Formate erweitert werden. Dazu mufi 
ein cntsprechender Document Viewer 19 geschaffen werden und dem Parser mufi ein entsprechendes 
Objekt zur Verfiigung gestellt werden, dafi die gratnmatikalischen Regeln beinhalted.. 




Abbildung 3: Gecko basiert auf seeks Subsystemen. Vorn Netzwerk-£?acA; End bis zum Rendering 
Engine, der die graphische Ausgabe generiert.fi] 

Die Funktionsweise der Komponenten wurde teilweise schon bei den Parser-Komponenten (2.3.1) 
umrissen. Hier win! nocli etwas detaillierter darauf eingegangen. 

Back End Das ist die Netzwerkkomponente. Wird ein neues Dokument ernpfangen, so wird zunachst 
der korrekte MIME-Typ bestimmt. Dieser Prozefi wird von ein paar Seiten unterstutzt: Neben der 
URL 20 und dem empfangenen HTTP Header werden in manchen Fallen auch direkt Bytes am Anfang 
des Dokuments ausgewertet. Der MIME-Typ wird verwendet um den passenden Document Viewer 

18 Extended Platform Component Object Model 

19 ist in der Lage den Dokumenttyp zu beschreiben und zu rendern 

20 Uniform Ressource Locator 
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(DV) dynamisch zu generieren. StandardmaBig bcinhalted Gecko DVs fiir HTML. XML und Gran- 
ken, 

Die empfangenen Datcn werden anschlictiend zum Parser weitergeschickt. 

Parser Der Parser ersteilt den Par.se- Tree (PT). Der PT beschreibt den Inhalt des erhaltenen 
Fragments eines Dokurnents symbolisch. Die Hauptaufgaben des PT sind die Interpretation der 
empfangenen Dafcen, die Prufung der strukturellen Korrektheit und das Entfernen unwichtiger Do- 
kumentteile. Der Parser schickt auf Grund des Inhaltes des PT Befehle zum Document Object die 
diesem mitteilen welche Elcmente konstruiert werden miissen. 

Style Bis der Stil eines Dokurnents feststeht flieflen Informationen aus selir vielen Quellen ein. Die 
erste wichtige Quelle ist der Prasentationskontext, der die physikalischen Eigenschaften des Ausgabe- 
gerats beschreibt (z.B. Drucker, Monitor), Daneben fiiefien die Standardeinsteilungen des Browsers 
(user-agent style sheet), eventuelle GSS-Informationen 21 sowie explizite IITML-Stil-Eigenschaften 
ein (z.B. BOLD- Tap). 

Layout Die La?/cmtf-Komponente bestimmt unter Zuhilfenalnne <ler passenden Stil- Eigenschaften 
die Geometrie jedes Elements des Dokurnrents. Das Resultat ist eine verschaehtelte Hierarchie soge- 
nannter Flow Objects 22 

Rendering Am Endc ist diese Komponente dafiir zustandig die Umsetzung der Geometrie in ein- 
zelne Pixel durchzufiihren, die auf dem Ausgabcgerat dargestcllt werden konnen. 

DOM Das W3U DOM Level wird von Gecko kompiell imlerstutzt. Die Umsetzung ven JavzScripi- 
Befehlen auf die C++-Schmttstelle, die Gecko bictet, erfolgt uber einen I DL- Compiler 23 . Damit ist 
der komplette Dokiimcnt-Inhalt zugrcifbar. 

3.4 Mozilla ActiveX Control 

Auch im Rahmen des Mozilla Projektes wird dcrzeit - analog zum WebBrowser Control von Microsoft 
(4.6) - ein ActiveX Control entwickelt, das die Funktionalitat des Gecko Layout Engine kapseln und 
einfach verfiigbar machen soli. Das Projekt befindct sich aber noch im Entwicklungsstadium. 

Das Control bietet exakt die selbe Schnitts telle wie das WebBrowser Control Die Entwickler von Mo- 
zilla haben dies so implcmcntiert, urn die Moglichkcit zu schaffen, beide Komponenten mit minimalen 
Anderungen am Code austauschen zu konnen. 

Durch das Mozilla Control wird es auch moglich die umfangrcichen und machtigen API's, die Gecko 
mitbringt, in anderen Programmiersprachen, als C-h-f 24 zu verwenden. Vorausgesetzt die Sprache 
unterstlitzt die Verwendung von ActiveX -Kom-ponenien. 

4 Microsoft Internet Explorer (IE) 
4.1 ActiveX 

Die ActiveX -Technologie wird deshalb in diesem Kapitel erortert, da sie in der gesamten Microsoft- 
Welt eine aufierst wichtige Rolle spielt. Der folgende Abschnitt ist aber bestenfalls ein grober Uber- 

21 Cascading Style Sheets 

22 kleinere geometrische Bereiche die zeilenweise wie ein Stack aufgebaut werden konnen. 

"interface Definition Language 

24 Die Gecko APIs sind in C-f + impiementiert. 
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blick, urn die Grundziige von ActiveX kenrierizuleriien. 

Einc ActiveX Komponente ist eine Datei, die ausfuhrbaren Code enthalt (z. B. eine EXE-, DLL- oder 
OCX-Datei). Der Code oricntiert sich an der AciweX-Spezmkation, die Art uiid Weise der Bereit- 
stellung der gekapselten Objekte genau regelt. Die ActiveX -Technologic erlaubt es einem Entwickler, 
verschiedener dieser Komponenten zu sammeln, und sie in cincr eigencn Applikation oder cinem 
Diertst zu vervvcnden. 

Zum einen gibt es Acrtt/eJf -Komponenten zu kaufen, die generische Dienste 25 zur Verfugung steiien. 
Die andere Moglichkeit ist die Entwicklung von Komponenten, die die eigenen Geschaftsprozesse 
unterstiitzen. Diese Komponenten konnen dann audi mit der ActiveX -Technologie mit kommerziellen 
Komponenten verknupft werden. Die Verwendung von getestetem, standardisiertem Code in der oben 
beschriebenen Weise wird als Component Software Development (CSD) bezeichnet. 

CSD mittels ActiveX darf man nicht mit objekt-orientierter Programmienmg (OOP) verwechseln. 
OOP ist eine Methode um objekt-basierte Software-Komponenten zu erstellen; ActiveX hingegen ist 
einc Technologic, mit der die Vcrkniipfung verschiedenster objekt-orientierter Komponenten erreicht 
werden kann. Auf andcrc Weise ausgedriickt: OOP beschaftigt sich mit der Erstcllung neuer Kom- 
ponenten, wahrend ActiveX das Ziel hat, eine Zusammenarbeit der Komponenten zu ermoglichen. 

Nehmen wir mal an, ich hatte mit Hilfe von Visual C++ eine Reihe nlitzlicher Objekte erstellt. Die 
Objekte konnten von jedem anderen C-f-h-Entwickler verwendet und erweitert werden. Wurde ich 
aber die Objekte in einer ActoeX-Komponente kapseln, so ware die Verwendung und Erweiterung 
der Objekte nicht mehr alleine auf C++ beschrarikt. Es ware dann von jeder Programmierumgebung, 
die ActiveX unterstiitzt, aus moglich die Objekte zu nutzen und zu verandern. 

4.2 Architektur des IE 

Der IE benutzt ActiveX Controls und das Active Document Interface um seine Komponenten zu 
verbinden. 




Abbildung 4: Die Architektur des Internet Explorer [3] 



^z. B. Komponenten fur numerische Analysen oder Elementc ciner graphischen Benuzerschnittstelle 
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IExplorer.exe ist die Top-Level-Anwendung. Diese kleine Applikation wird instantiiert wenn der 
IE geladen wird. Sie verwendet die IE-Komponenten urn folgende Aufgaben ausfiihren zu konnen: 
Navigation, iftstory-Verwaltung, Boohrnark-VeTw&ltxmg, das Parsen und Rendern von HTML-Code 
U.S.W. Diese Applikation ist auch flir die GUI 26 des IE verantwortlich. Sie liefert u. a. die Toolbars 
und den Frame, in dem der IE dargestellt wird. IExplorer.exe beinhalted direkt die ,.Shdocvw.dir\ 

Shdocvw.dll beinhalted eine ,,Active Document"-Komponente. 1m Normalfall ist dies die Ms- 
htmidll. Sie kann aber dynamisch durch eine andere solche Komponente (z. B. einc „Microsoft Offi- 
ce"- Applikation) ersetzt werden wenn der Benutzer ein Dokuirient mit entsprechendem Typ betrach- 
ten will Shdocvw.dll bietet die Funktionalitat, die fur die Navigation, das Darstellen eines verlinkten 
Dokumentes im gleichen Browserfenster, Bookmark- und //zs£on/-Management, sowie das Darstellen 
von Bildern benotigt wird. 

Diese DLL bietet zudem eine Schnittstelle, die es erlaubt sie als ActiveX Control in andere Anwen- 
dungen einzubinden. Deshaib wird diese Komponente auch oft als WebBrowser Control bezeichnet. 

Mshtml.dll ist die Komponente, die seit dem IE 4.0 fur das Parsen und Rendern von HTML-Seiten 
zustandig ist. Daneben stellt sie auch noch das DHTML Object Model zur Verfiigung. Iimerhalb dieser 
DLL laufen die Scripting Engines, die Microsoft Virtual Machine, die ActiveX Controls, Plug-ins und 
andere Objekte, die von einer HTMLr-Seite referenziert werden konnten. Die Kommunikation mit der 
DLL geschieht iiber die COM 27 -Schnittstelle. 

Die Architektur ist in einem Punkt rekursiv. Werden Frames verwendet, so gibt es in der oberstcn 
MSIITML-Instanz fiir jeden Frame eine SHDOCVW-Instanz, die alle wiederum eine MSIITML- 
Instanz enthalten. 

4.3 ActiveX Scripting Engine 

Durch das Konzept des ActiveX Scripting Engine (ASE) verwirklicht Microsoft seit dem IE Version 
4,0 eine sehr offene und erweiterbare Umgebung fur Scripting Engines. Es kann fiir buchstablich jede 
Skriptsprache ein eigener SE gebastelt werden, der auch relativ einfach eingebunden werden kann. Au- 
fierdem konnen die Skriptsprachen in einem Web-Dokument relativ beliebig durcheinandergewurfelt 
werden, was ihre Interpretation nicht stort. 

Um einen SE fiir eine noch nicht unterstiitztc Skriptsprache in das System zu integrieren mufi lediglich 
eine entsprechende Parser-DLL installiert werden, die das ActiveX Scripting Interface implementiert. 
Ober diese Schnittstelle kann der ASE auf die DLL zugreifen. Natiirlich treten Probleme auf, wenn 
die Skriptsprache auf einem anderen Browser interpretiert werden soil. Es mufi also in diesem Fall 
sichergestellt werden, dan der SE auch auf anderen Browsern installiert ist, oder installiert werden 
kann. 

4.4 Browser Extensions 

Die Microsoft Browser Extensions ermoglichen es Entwicklcrn auf einfache Art und Weise Zugriff 
auf ihre eigenen Browser-Erweitenmgen zu gestatten, indem sie die Standard-BenutzerschnittsteUe 
mit eigenen Elementen (z.B. ein Explorer Bar) crweitern konnen. Dieses Feature erlaubt es seit 
dem IE version 4.0 Explorer Bars zu integrieren, und das K on text- Men ii^ mit eigenen Eintragen zu 
crganzen. Seit dem IE Version 5 ist es zusatzlich mdglich Eintrage in das Tbo/s-Menu einzufiigen, und 
cs konnen eigene Buttons in die Toolbars eingefiigt werden. Seit der Version 5 gestatten die Browser 

26 Graphical User Interface 
27 Component Object Model 

^Normalerweise erreichbar iiber die rechte Maustaste. 
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Extensions auch den Zugriff auf Win32-Applikationen und exteme Skripte. Dieser ZugrifF kann uber 
Menueintrage und zusatzliche Buttons zur Verfiigung gcstellt werden. 

Um beipielsweise einen Button auf der Oberflache einzufiigen braucht man Kenntnisse fiber die Win- 
dows Registry und Globally Unique Identifiers (GU1D). Der Button wird uber eine ganze Latte von 
Registry-EmtT&gen festgelegt und bcschrieben. Programmierkenntnisse sind eigentlich nicht erforder- 
lich. 

4.5 Shell Helper API 

Seit dem IE Version 5 bietet Microsoft die Shell Helper API, die u. a. fur die Bookmark- Verwaltung 
zustandig ist. Das Neue daran ist die Moglichkeit Bookmarks iiber das Internet auszutanschen und 
zu synchronisieren. 

Jeder kennt das Problem, dafi sich ein entsprechender Bookmark-T&ir&v&g immer genau auf dem 
Rechner befindet, auf dem man gerade nicht arbeitet. Mit dem Konzept, das die Shell Helper API 
bietet wird es z. B. fiir ISP's 29 moglich eine Ablagc der Bookmarks im Internet anzubieten, wo sie 
von jedem Rechner aus einfach zugrcifbar waren. 

Sobald der Benutzer dann im IE seine Favoriten-Liste aufruft wird die Liste automatisch mit der 
Liste im Internet synchronisiert, wodurch cr immer die aktuellen Bookmarks auf dem aktuellen 
Arbeitsrechner zur Verfiigung hatfce. 

4.6 WebBrowser Control 

Wie schon oben erwahnt kann viel der Punktionalitat, die der Internet Explorer mitbringt, iiber ein 
ActiveX Control in eigene Applikationen eingebunden werden. Einer Applikation. die Has Control 
verwendet, stent fast die komplette Funktionalitat des IE zur Verfiigung: Ausfuhrung von Skripten, 
DOM, DHTML, Java, das Darstellen von HTML-Seiten, XML u.s. w.. Es wird die selbe Oberflache 
gezeigt, die auch im IE sichtbar ist. Lediglich das umgebende Fenster fehlt. 

Die Komponente kann dann objektorientiert uber Methoden und Attribute gesteuert und abgefragt 
werden. Zudem bietet die Komponente auch noch ein Event Model das z. B. vor dem Darstellen einer 
neuen Seite ein Ereignis auslost, auf das dann entsprechend reagiert werden kann. 
Das WebBrowser Control ist auf jedem Windows- System verfugbar, auf dem ein IE installiert ist. 

5 Zusammenfassung und Ausblick 

Die Nutzung von Web-Browsern an der Schnittstelle zwischen Informationssysteinen und Benutzer 
bietet viele Vorteile gegeniiber der Verwendung spezialisierter Anwendungen. Mit den heute verfiigba- 
ren Browscr-Tcchnologien kann - wenn bestimmte Rahmenbedingungen erfullt sind 30 - die komplette 
Funktionalitat einer „normalen", auf einem Rechner laufenden, proprietaren Anwendung nachgebil- 
det werden. 

Ein Vorteil der Webtechnologie ist, dafi als Basisausstattung nur ein Browser benobigt wird, um auf 
ein Informationssystem zugreifen zu konncn. Diese Voraussetzung ist heute wahrscheinlich schon auf 
den meisten Rechnern erfiillt. Zu den einfachen Mindestbedingungen kommt der gewohnte Umgang 
mit dem Browser, was heute auch als gegeben angenommen werden kann. 
Diese einfache Infrastruktur bedeutct eine konkrete Kostenersparnis, z. B. fiir ein Unternehmen. 

29 Internet Service Provider 

30 Kontrolle iiber die Browser- {Configuration des Benutzers, z. B. im Intranet 
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Ein weiterer Vorteil. der Nutzung von Web-Browsern als Zugangssoftware, ist die Skalierbarkeit 
solcher Systeme. Ein Informal; iorissystem. das bereits im Intranet verfugbar ist kann im Normalfall 
mit geringem Aufwand auch im Internet verfugbar gemacht werden. 

Es gibt allerdings einen Unterschied, in welchem Grad die Moglichkciten, die Web-Browser heute 
bieten, eingesetzt werden konnen. 

In einem System das lediglich im Intranet eingesetzt wird gibt es so gut wie keine Einschrankungen. 
Dies liegt daran. dafi die relevante, eingesetzte Software komplett der System- Administration bekannt 
ist und kontrolliert werden kann. In soldi einem Umfeld konnen auch neue Teehnolgie-Features schnell 
mit Erfolg eingesetzt werden. 

Im Internet bietet sich cine andcre Situation. Wird ein Informationssystem im Intenet verfugbar 
gemacht, so mufi genau abgcwagt werden welche Technolgien bei den meisten Benutzern erwartet 
werden konnen. Es ware wenig vorteilhaft ein brandneues Portal ins Internet zu stellen, das aber 
nur 5Internet-Besucher nutzen konnen. da der Rest nicht uber ausreichende ausgestattete Browser 
verfugt. Dies sind einige der kritischen Technologien: Cookies, JavaScript, Java, Verwendung seltener 
Scrip tsprachen. CSS, die Annahme der Benutzer habe bestimmte Plug- ins installiert, usw. 

Auf Grund der genannten Vorteile - vor allem der Einfachheit und Verfiigbarkeit - ist es aber zu 
erwarten, dafi die Verwendung von Web-Browser als Zugangsmedium immer wichtiger werden wird. 
Der aktuell sehr stark wachsende Bereich der Application Service Provider (ASP) 31 ist ein Indiz 
hierfur. Fiir die Zukunft kann auch mit Systemen gerechnet werden, die noch einen Schritt weiter 
gehen und nur noch einen Web-Browser installiert haben. Das System besitzt dann uber keinen 
Plattenspeicher mehr. und alle Anwendungen sind auschliefilich online verfugbar. 



3l Anbieter, die Applikationen uber das Internet zur Verfugung stellen. Die Programme sind nicht lokal installiert, 
sondern werden uber den Web-Browser genutzt und gesteuert. 
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